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(57) Abstract: An interlocking archiiecture for a software interface and a bar code scanner. Upon power-up. a handshaking opera- 
tion is performed between a scanner ( 1 600) having a scanner processor (2600) and a computer processor (261 2) of a computer (302) 
based upon the code stored in the NV memory (2602) of the scanner (1600) and a unique code associated with the software interface 
running on the computer (302 ). A wedge ( 1 608) is provided as an interface mechanism for the scanner ( 1 600) and a keyboard (1610) 
to a keyboard pon (2500) of the computer (302). The handshaking occurs through the wedge ( 1 608) via a keyboard interface ( 26 1 0) 
to the processor (2600) such that a successful handshake directs the processor (2600) to engage a switch (2604) which enables power 
10 a sensing head (2606) for read optically encoded information. The software interface operates from a computer memor>' (2614) 
associated with the processor (2612) whereby an unsuccessful handshake using unique number of the software interface by the pro- 
cessor (2612) sends a disabling signaJ through the keyboard circuit (261 8) through the wedge (1608) to the scanner processor (2600) 
to disengage the switch (2504) to drop power to the sensor head (2606). The handshaking operation is performed on a regular basis 
during system power-up to ensure that the original software interface and scanner (1600) are siill in use. 
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BAR CODE SCANNER AND SOFTWARE INTERFACE INTERLOCK 

TECHNICAL FIELD OF THE INVENTION 

This invention is related to interlocking mechanisms between software and hardware, 
and more particularly, to interlocking use of a bar code scanner with a software interface. 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application is a Continuation-in-Part of pending U.S. Patent Application Serial No. 
09/378,221 (Atty Dkt. No. PHLY-24,669) entitled "METHOD AND APPARATUS FOR 
ACCESSING A REMOTE LOCATION BY SCANNING AN OPTICAL CODE." 
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BACKGROUND OF THE INVENTION 

The technological advances in the fabrication of smaller integrated circuits have resulted 
in controllers and microprocessors being implemented in a wide variety of applications, where 
in the past such implementations have been considered impossible or very expensive. The 
introduction of these "smart" or "intelligent" embodiments have a significant impact on 
commercial ventures producing such products. Therefore, it becomes important to the 
manufacturer of the product to exercise control over the nature, origin and/'or quality of 
software wnth which will be used. This protects the use of such products from competitive 
intrusion, by ensuring that such products can only be used under certain circumstances. 

A prime example of this philosophy being put into action is evident in the home video 
game industry. Nintendo Co., Ltd,, a prominent vendor of such systems protects its place in 
this very competitive area of the market by ensuring that only its game modules will work w^ith 
its gaming consoles. Unauthorized third-party vendors are prevented from freely producing 
modules that work with Nintendo 's gaming consoles, not only legally by contracts and licensing 
agreements, but also technically by secure handshaking protocols imposed betv^^een the modules 
and the console. This way, Nintendo protects its long-term viability and survival in the gaming 
market. Such a protection mechanism also reduces the number of consumer complaints 
presented to a manufacturer making such products. Those products which have been tested for 
compatibility are guaranteed to work, and those products which have not, are likely to cause 
consumer discontent due to operational failures and the like. 

A device becoming more prominent in the marketplace is the bar code scanner. 
Scanners come in a variety of configurations from standalone pens to input devices which 
connect to computer ports through an interface device called a "wedge," and in some 
implementations, hand-held telecommunication dev^ices. Advances in bar code technology are 
expanding the amount of information which can be encoded in the bar code, making the scarmer 
an even more important for facihtating many different types of operations. Therefore, it is 
desirable to provide a scanner which is interlocked with a particular piece of software to ensure 
that misuse is prevented, and that third-party vendors cannot illegally reproduce the system 
causing the ow^ner of such a system lost revenue. 
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SUMMARY OF THE INVEiNTION 

The present invention disclosed and claimed herein, in one aspect thereof, comprises 
a method for controlling a scanner with a software interface. A scanner is provided which is 
operable to read scannable information. The scanner is connected to a computer which operates 
the software interface for processing the scannable information. An encrypted handshaking 
operation is performed between the software interface and the scarmer prior to allowing the 
scanner to become operable to read the scarmable information. 
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BRIEF DESCRIPTION OF THE DILWVINGS 

For a more complete understanding of the present invention and the advantages thereof, 
reference is now made to the following description taken in conj unction with the accompanying 
Drawings in which: 

FIGURE 1 illustrates a block diagram of the preferred embodiment; 

FIGURE 2 illustrates the computer components employed in this embodiment; 

FIGURE 3 illustrates system interactions over a global network; 

FIGURES 4a-4e illustrate the various message packets transmitted between the source 
PC and network servers used in the preferred embodiment; and 

FIGURE 5 is a flowxhart depicting operation of the system according to the preferred 
embodiment. 

FIGURE 6 illustrates a flowchart of actions taken by the Advertiser Reference Server 
("ARS") server; 

FIGURE 7 illustrates a flowchart of the interactive process between the source computer 
and ARS; 

FIGURE 8 illustrates a web browser page receiving the modified UR_L/advertiser 
product data according to the preferred embodiment; 

FIGURE 9 illustrates a simplified block diagram of the disclosed embodiment; 

FIGURE 1 0 illustrates a more detailed, simplified block diagram of the embodiment of 
FIGUTIE9; 

FIGURE 11 illustrates a diagrammatic view of a method for performing the routing 
operation; 

FIGURE 12 illustrates a block diagram of an alternate embodiment utilizing an optical 
region in the video image for generating the routing information; 

FIGURE 13 illustrates a block diagram illustrating the generation of a profile with the 
disclosed embodiment; 

FIGURE 14 illustrates a flowchart for generating the profile and storing at the ARS; 

FIGURE 15 illustrates a flowchart for processing the profile information when 
information is routed to a user; 

FIGLTIE 16 illustrates a general block diagram of a disclosed embodiment; 

FIGURE 17 illustrates the conversion circuit of the wedge interface; 
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FIGURE 18 illustrates a sample message packet transmitted from the user PC to the 

ARS; 

FIGURE 19 illustrates a more detailed block diagram of the routing of the message 
packets between the various nodes; 

FIGURE 20 illustrates a block diagram of a browser window, according to a disclosed 
embodiment; 

FIGURE 21 illustrates a diagrammatic view of information contained in the .AJIS 
database; 

FIGURE 22 illustrates a flowchart of the process of receiving information for the user' s 
perspective; 

FIGURE 23 illustrates a flowchart according to the ARS; 

FIGURE 24 illustrates a flowchart of the process performed at the E-commerce node; 
FIGURE 25 illustrates a general diagram in context of a disclosed embodiment; 
FIGURE 26 illustrates a more detailed block diagram of a disclosed embodiment; 
FIGURE 27 illustrates an altemative embodiment incorporating a network; 
FIGURE 28 illustrates a flowchart of the operation of the scanner and software interface 
used in a local mode; and 

FIGLUE 29 illustrates a flowchart of operation in a remote mode. 



wo 01/57780 



PCT/USOl/02762 



6 

DETAILED DESCRIPTION OF THE INVENTION 

Referring now to FIGURE 1 , there is illustrated a block diagram of a system for 
controlling a personal computer ("PC") 112 via an audio tone transmitted over a wireless 
system utilizing a TV. In the embodiment illustrated in FIGURE 1, there is provided a 
transmission station 101 and a receive station 1 1 7 that are connected via a communication link 
108. The transmission station 101 is comprised of a television program source 104, which is 
operable to generate a program in the form of a broadcast signal comprised of video and audio. 
This is transmitted via conventional techniques along channels in the appropriate frequencies. 
The program source is input to a mixing device 106, which mixing device is operable to mix 
in an audio signal. This audio signal is derived from an audio source 100 which comprises a 
coded audio signal which is then modulated onto a carrier which is combined with the 
television program source 104. This signal combining can be done at the audio level, or it can 
even be done at the RF level in the from of a different carrier. However, the preferred method 
is to merely sum the audio signal from the modulator 1 02 into the audio charmel of the program 
that is generated by the television program source 1 04. The output thereof is provided from the 
mixing device 106 in the form of broadcast signal to an anteima 107, which transmits the 
information over the communication link 108 to an antenna 109 on the receive side. 

' On the receive side of the system, a conventional receiver 1 10, such as a television is 
provided. This television provides a speaker output which provides the user with an audible 
signal. This is typically associated with the program. However, the receiver 110 in the 
disclosed embodiment, also provides an audio output jack, this being the type RCA jack. This 
jack is utilized to provide an audio output signal on a line 1 1 3 which is represented by an audio 
signal 111. This line 1 13 provides all of the audio that is received over the communication link 
108 to the PC 1 12 in the audio input port on the PC 112. However, it should be understood 
that, although a direct connection is illustrated from the receiver 110 to the PC 112, there 
actually could be a microphone pickup at the PC 1 1 2 which could pick the audio signal up. In 
the disclosed embodiment the audio signal generated by the advertiser data input device 100 
is audible to the human ear and, therefore, can be heard by the user. Therefore, no special 
filters are needed to provide this audio to the PC 112. The PC 1 1 2 is operable to run 
programs thereon which t>pically are stored in 'a program file area 1 16. These programs can 
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be any t>pe of programs such as word processing programs, application programs, etc. Ln the 
disclosed embodiment, the program that is utilized in the system is what is referred to as a 
'^browser." The PC 1 12 runs a browser program to facihtate the access of information on the 
netv^'ork, for example, a global communication network known as the "Internet" or the World- 
5 Wide-Web ("Web"). The browser is a hypertext-linked application used for. accessing 

information. Hypertext is a term used to describe a particular organization of information 
within a data processing system, and its presentation to a user. It exploits the computer's ability 
to link together information from a wide variety of sources to provide the user with the ability 
to explore a particular topic. The traditional style of presentation used in books employs an 

1 0 organization of the information which is imposed upon it by limitations of the medium, namely 
fixed sized, sequential paper pages. Hypertext systems, however, use a large number of units 
of text or other types of data such as image information, graphical information, video 
information, or sound information, which can vary in size. A collection of such units of 
information is termed a hypertext document, or where the hypertext documents employ 

1 5 information other than text, hypermedia documents. Multimedia communications may use the 

Hypertext Transfer Protocol ("HTTP"), and files or formatted data may use the Hypertext 
Markup Language ("HTML"). This formatting language provides for a mingling of text, 
graphics, sound, video, and hypertext links by "tagging" a text document using HTML. Data 
encoded using HTML is often referred to as an "HTML document," an "HTML page," or a 

20 "home page." These documents and other Internet resources may be accessed across the 
net\vork by means of a network addressing scheme which uses a locator referred to as a 
Uniform Resource Locator ("URL"), for example, "http://www.digital.com." 

The Internet is one of the most utilized networks for interconnecting distributed 
computer systems and allows users of these computer systems to exchange data all over the 

25 world. Connected to the Internet are many private networks, for example, corporate o> 

commercial networks. Standard protocols, such as the Transport Control Protocol ("TCP") and 
the Internet Protocol ("IP") provide a convenient method for communicating across these 
diverse networks. These protocols dictate how data are formatted and communicated. As a 
characteristic of the Internet, the protocols are layered in an IP stack. At higher levels of the 

30 IP stack, such as the application layer (where HTTP is employed), the user information is more 
readily visible, while at lower levels, such as the network level (where TCP/IP are used), the 
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data can merely be observed as packets or a stream of rapidly moving digital signals. 
Superimposed on the Internet is a standard protocol interface for accessing Web resources, such 
servers, files, Web pages, mail messages, and the like. One way that Web resources can be 
accessed is by browsers made hy Netscape® and Microsoft Internet Explorer®. 

Referring again now to FIGURE 1 , the user can load this program with the appropriate 
keystrokes such that a browser window will be displayed on a display 1 1 8. In one embodiment, 
the user can run the browser program on the PC 1 1 2 such that the browser window is displayed 
on the display 1 18. While watching a preferred program, the user can also view display 1 IS. 
When an audio signal is received by the receiver 1 10 and the encoded information is contained 
therein that was input thereto by the adveniser, the PC 112 will then perform a number of 
operations. The first operation, according to the disclosed embodiment, is to extract the audio 
information within the received audio signal in the form of digital data, and then transmit this 
digital data to a defined location on the global communication network via a modem connection 
114. This connection will be described hereinbelow. This information will be relayed to a 
proprietary location and the instructions sent back to the PC 112 as to the location of the 
advertiser associated with the code, and the PC 1 12 will then effect a communication link to 
that location such that the user can view on the display 118 information that the advertiser, by 
the fact of putting the tone onto the broadcast channel, desires the viewer to view. This 
information can be in the form of interactive programs, data files, etc. In one example, when 
an advertisement appears on the television, the tone can be generated and then additional data 
displayed on the display 118. Additionally, a streaming video program could be played on the 
PC received over the network, which streaming video program is actually longer than the 
advertising segment on the broadcast. Another example would be a sports game that would 
broadcast the tone in order to allow a user access to information that is not available over the 
broadcast network, such as additional statistics associated with the sports program, etc. 

By utilizing the system described herein with respect to the disclosed embodiment of 
FIGURE 1, an advertiser is allov^^ed the ability to control a user's PC 1 12 through the use of 
tones embedded within a program audio signal. As will descried hereinbelow, the disclosed 
embodiment utilizes particular routing information stored in the PC 112 which allows the 
encoded information in the received audio signal to route this information to a desired location 
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on the network and then allow other routing information to be returned to the PC 112 for 
control thereof to route the PC 1 12 to the appropriate location associated with that code. 

Referring now to FIGURE 2, there is illustrated a computer 204, similar to computer 
1 12, connected to display information on display 118. The computer 204 comprises an internal 
audio or "sound" card 206 for receiving the transmitted audio signal through receive antenna 
109 and receiver 1 10. The sound card 206 typically contains analog-to-digital circuitry for 
converting the analog audio signal into a digital signal. The digital signal may then be more 
easilymanipulated by software programs. The receiver 1 10 separates the audio signal from the 
video signal. A special trigger signal located within the transmitted advertiser audio signal 
triggers proprietary software running on the computer 204 which launches a communication 
application, in this particular embodiment, the web browser application located on the PC 204. 
Coded advertiser information contained within the audio signal is then extracted and appended 
with the address of a proprietary server located on the communication network. The remote 
sender address is in the form of a URL. This appended data, in addition to other control codes, 
is inserted directly into the web browser application for automatic routing to the communication 
network. The web browser running on PC 204, and communicating to the network with a 
through an internal modem 208, in this embodiment, transmits the advertiser information to the 
remote server. 

The remote server cross-references the advertiser product information to the address of 
the advertiser server located on the network. The address of the advertiser server is routed back 
through the PC 204 web browser to the advertiser server. The advertiser product information 
is returned to PC 204 to be presented to the viewer on display 118. In this particular 
embodiment, the particular advertiser product information displayed is contained within the 
advertiser's web page 212. As mentioned above, the audio signal is audible to the human ear. 
Therefore the audio signal, as emitted from the TV speakers, may be input to the sound card 
206 via a microphone. Furthermore, the audio signal need not be a real-time broadcast, but may 
be on video tapes, CDs, DVD, or other media which may be displayed at a later date. With the 
imminent implementation of high definition digital television, the audio signal output from the 
TV may also be digital. Therefore, direct input into a sound card for A/D purposes may not be 
necessar>'. but alternative interfacing techniques to accommodate digital-to-digital signal 
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formats would apply. 

Referring now to FIGURE 3 , there is illustrated a source PC 302, similar to PCs 204 and 
112, connected to a global communication network 306 through an interface 304. In this 
embodiment, the audio signal 1 1 1 is received by PC 302 through its sound card 206. The audio 
signal 1 1 1 comprises a trigger signal which triggers proprietary software into launching a web 
browser application residing on the PC 302. The audio signal 1 1 1 also comprises advertiser 
product information which is extracted and appended with URL information of an Advertiser 
Reference Server (**ARS") 308. The ARS 308 is a system disposed on the network that is 
defined as the location to which data in the audio signal 111 is to be routed. As such, data in 
the audio signal 11 1 will always be routed to the ARS 308, since a URL is unique on the 
nenvork system. 

Connected to the ARS 308 is a database 310 of product codes and associated 
manufacturer URLs. The database 310 undergoes a continual update process which is 
transparent to the user. As companies sign-on, e.g., subscribe, to this technology, manufacturer 
and product information is added to the database 3 1 0 without interrupting operation of the 
source PC 302 with frequent updates. When the advertiser server address URL is obtained 
from- the ARS database 3 1 0, it and the request for the particular advertiser product information 
is automatically routed back through the web browser on PC 302, over to the respective 
advertiser server for retrieval of the advertiser product information to the PC 302. It should be 
noted that although the disclosed invention discusses a global communication network, the 
system is also applicable to LANs, WANs, and peer-to-peer network configurations. It should 
be noted that the disclosed architecture is not limited to a single source PC 302, but may 
comprise a plurality of source PCs, e.g., PC 300 and PC 303. Moreover, a plurahty of ARS 308 
systems and advertiser servers 312 may be implemented, e.g., ARS 314, and advertiser server 
A 316, respectively. 

The information transactions, in general, which occur between the networked systems 
of this embodiment, over the communication network, are the following. The web browser 
running on source PC 302 transmits a message packet to the ARS 308 over Path ''A." The ARS 
308 decodes the message packet and performs a cross-reference function with product 



wo 01/57780 



PCT/USOl/02762 



11 

information extracted from the received message packet to obtain the address of an advertiser 
server 312. A new message packet is assembled comprising the advertiser server 312 address, 
and sent back to the source PC 302 over Path "B/' A "handoff ' operation is perfomied 
whereby the source PC 302 browser simply reroutes the information on to the advertiser server 
312 over Path "C," with the appropriate source and destination address appended. The 
advertiser server 312 receives and decodes the message packet. The request-for-adyertiser- 
product-information is extracted and the advertiser 3 1 2 retrieves the requested information from 
its database for transmission back to the source PC 302 over Path *'D."' The source PC 302 then 
processes the information, i.e.,. for display to the viewer. The optional Path **E" is discussed 
hereinbelow. It should be noted that the disclosed methods are not limited to only browser 
communication applications, but may accommodate, with sufficient modifications by one 
skilled in the art, other communication applications used to transmit information over the 
Internet or communication network. 

Referring now to FIGURE 4a, the message packet 400 sent from the source PC 302 to 
ARS 308 via Path "A" comprises several fields. One field comprises the URL of the ARS 308 
which indicates where the message packet is to be sent. Another field comprises the advertiser 
product code or other information derived from the audio signal 111, and any additional 
overhead information required for a given transaction. The product code provides a link to the 
address of the advertiser server 312, located in the database 310. Yet another field comprises 
the netw^ork address of the source PC 302. In general, network transmissions are effected in 
packets of information, each packet providing a destination address, a source address, and data. 
These packets vary depending upon the network transmission protocol utilized for 
communication. Although the protocols utilized in the disclosed embodiment are of a 
conventional protocol suite commonly known as TCP/IP, it should be understood that any 
protocols providing the similar basic functions can be used, with the primary requirement that 
a browser can forward the routing information to the desired URL in response to keystrokes 
being input to a PC. However, it should be understood that any protocol can be used, with the 
primary requirement that a browser can forward the product information to the desired URL in 
response to keystrokes being input to a PC. Within the context of this disclosure, '^message 
packet'' shall refer to and comprise the destination URL, product information, and source 
address, even though more than a single packet must be transmitted to effect such a 
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transmission. 

Upon receipt of the message packet 400 from source PC 302, ARS 308 processes the 
information in accordance with instructions embedded in the overhead information. The ARS 
308 specifically will extract the product code information from the received packet 400 and, 
5 once extracted, will then decode this product code information. Once decoded, this information 

is then compared with data contained within the ARS advertiser database 3 1 0 to determine if 
there is a "hit." If there is no '*hit" indicating a match, then information is returned to the 
browser indicating such. If there is a "hit/* a packet 402 is assembled which comprises the 
address of the source PC 302, and information instructing the source PC 302 as to how to 

1 0 access, directly in a "handoff operation, another location on the network, that of an advertiser 

server 312. This type of construction is relatively conventional with brow^sers such as 
Netscape® and Microsoft Internet Explorer® and, rather than displaying information from the 
ARS 308, the source PC 302 can then access the advertiser server 312. The ARS 308 transmits 
the packet 402 back to source PC 302 over Path "B." Referring now to FIGURE 4b, the 

15 message packet 402 comprises the address of the source PC 302, the URL of the advertiser 
server 312 embedded within instructional code, and the URL of the ARS 308. 

Upon receipt of the message packet 402 by the source PC 302, the message packet 402 
is disassembled to obtain pertinent routing information for assembly of a new message packet 
404. The w^eb browser running on source PC 302 is now directed to obtain, over Path "C," the 
20 product information relevant to the particular advertiser server 312 location information 
embedded in message packet 404. Referring now to FIGURE 4c, the message packet 404 for 
this transaction comprises the URL of the advertiser server 312, the request-for-product- 
information data, and the address of the source PC 302. 

Upon receipt of the message packet 404 from source PC 302, advertiser server 312 
25 disassembles the message packet 404 to obtain the request-for-product-information data. The 

advertiser server 312 then retrieves the particular product information from its database, and 
transmits it over Path "D" back to the source PC 302. Referring now to FIGURE 4d, the 
message packet 406 for this particular transaction comprises the address of the source PC 302, 
the requested information, and the UKL of the adveniser ser\''er 312. 
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Optionally, the ARS 308 may make a direct request for product information over Path 
"E" to advertiser server 312. In this mode, the ARS 308 sends information to the advertiser 
server 312 instructing it to contact the source PC 302. This, however, is unconventional and 
requires more complex software control. The message packet 408 for this transaction is 
illustrated in FIGURE 4e, which comprises the URL of the advertiser ser\'er 312, the request- 
for-product-information data, and the address of the source PC 302. Since product information 
is not being returned to the ARS 308, but directly to the source PC 302, the message packet 408 
requires the return address to be that of the source PC 302. The product information is then 
passed directly to PC 302 over Path "D." 

Referring now to FIGURE 5, the method for detecting and obtaining product 
information is as follows. In decision block 500, a proprietary application running resident on 
a source computer PC 302 (similar to PC 204) monitors the audio input for a special trigger 
signal. Upon detection of the trigger signal, data following the trigger signal is decoded for 
further processing, in function block 502. In function block 504, the data is buffered for further 
manipulation. In decision block 506, a determination is made as to whether the data can be 
properly authenticated. If not, program flow continues through the '*N" signal to function block 
520 where the data is discarded. In function block 522, the program then signals for a 
retransmission of the data. The system then waits for the next trigger signal, in decision block 
500. If properly authenticated in decision block 506, program flow continues through the ''Y'' 
signal path where the data is then used to launch the web browser application, as indicated in 
function block 508. In function block 510, the web browser receives the URL data, which is 
then automatically routed through the computer modem 208 to the network interface 304 and 
ultimately to the network 306. In function block 514, the ARS 308 responds by returning the 
URL of advertiser server 3 12 to the PC 302. In function block 516, the web browser rurming 
on the source PC 302, receives the advertiser URL information from the ARS 308, and 
transmits the URL for the product file to the advertiser server 312, In block 518, the advertiser 
ser\'er 312 responds by sending the product information to the source PC 302 for processing. 

The user 'may obtain the benefits of this architecture by simply downloading the 
proprietary software over the network. Other methods for obtaining the software are well- 
known; for example, by CD, diskette, or pre-loaded hard drives. 
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Referring now to FIGURE 6, there is illustrated a flowchart of the process the ARS 308 
may undergo when receiving the message packet 400 from the source PC 302. In decision 
block 600, the ARS 308 checks for the receipt of the message packet 400. If a message packet 
400 is not received, program flow moves along the "N" path to continue waiting for the 
message. If the message packet 400 is received, program flow continues along path *'Y" for 
message processing. Upon receipt of the message packet 400, in function block 602, the ARS 
308 decodes the message packet 400. The product code is then extracted independently in 
function block 604 in preparation for matching the product code with the appropriate advertiser 
server address located in the database 3 1 0. In function block 606, the product code is then used 
with a lookup table to retrieve the advertiser server 312 URL of the respective product 
information contained in the audio signal data. In function block 608, the ARS 308 then 
assembles message packet 402 for transmission back to the source PC 302. Function block 6 1 0 
indicates the process of sending the message packet 402 back to the source PC 302 over Path 

Referring now to FIGURE 7, there is illustrated a flowchart of the interactive processes 
betw^een the source PC 302 and the advertiser server 3 12. In function block 700, the source PC 
302 receives the message packet 402 back from the ARS 308 and begins to decode the packet 
402. In function block 702, the URL of the advertiser product information is extracted from 
the message packet 402 and saved for insertion into the message packet 404 to the adv ertiser 
server 312. The message packet 404 is then assembled and sent by the source PC 302 over Path 
*'C" to the advertiser server 312, n function block 704. While the source PC 302 waits, in 
function block 706, the advertiser server 312 receives the message packet 404 from the source 
PC 302, in function block 708, and disassembles it. The product information location is then 
extracted from the message packet 404 in function block 710. The particular product 
information is retrieved from the advertiser server 312 database for transmission back to the 
source PC 302. In function block 712, the product information is assembled into message 
packet 406 and then transmitted back to the source PC 302 over Path "D." Returning to the 
source PC 302 in function block 714, the advertiser product information contained in the 
message packet 406 received from the advertiser serv'er 312, is then extracted and processed 
in function block 716. 
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Referring now to FIGURE 8, after receipt of a trigger signal, a web browser application 
on a source PC 302 is automatically launched and computer display 800 presents a browser 
page 802. Proprietary software running on the source PC 302 processes the audio signal data 
after being digitized through the sound card 206. The software appropriately prepares the data 
for insertion directly into the web browser by extracting the product information code and 
appending keystroke data to this information. First, a URL page 804 is opened in response to 
a Ctrl-O command added by the proprietary software as the first character string. Opening URL 
page 804 automatically positions the cursor in a field 806 where additional keystroke data 
following the Ctrl-O command will be inserted. After URL page 804 is opened, the hypertext 
protocol preamble http:// is inserted into the field 806. Next, URL information associated with 
the location of the ARS 308 is inserted into field 806. Following the ARS 308 URL data are 
the characters /? to allow entry of variables immediately following the /? characters. In this 
embodiment, the variable following is the product information code received in the audio 
signal. The product code information also provides the cross-reference information for 
obtaining the advertiser URL from the ARS database 310. Next, a carriage return is added to 
send the URL/product data and close the window 804. After the message packet 400 is 
transmitted to the ARS 308 fi-om the source PC 302, transactions fi"om the ARS308, to the 
source PC 302, to the advertiser server 3 1 2, and back to the source PC 302, occur quickly and 
are transparent to the viewer. At this point, the next information the viewer sees is the product 
information which was received fi*om the advertiser sen'-er 312. 

Referring now^ to FIGURE 9, there is illustrated a block diagram of a more simplified 
embodiment. In this embodiment, a video source 902 is provided which is operable to pro\ ide 
an audio output on an audio cable 901 which provides routing information referred to by 
reference numeral 904. The routing information 904 is basically information contained within 
the audio signal. This is an encoded or embedded signal. The important aspect of the routing 
information 904 is that it is automatically output in realtime as a function of the broadcast of 
the video program received over the video source 902. Therefore, whenever the program is 
being broadcast in realtime to the user 908, the routing information 904 will be output 
whenever the producer of the video desires it to be produced. It should be understood that the 
box 902 representing the video source could be any type of media that will result in the routing 
information being output. This could be a cassette player, a DVD player, an audio casseiie. a 
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CD ROM or any such media. It is only important that this is a program that the producer 
develops which the user 908 watches in a continuous or a streaming manner. Embedded within 
that program, at a desired point selected by the producer, the routing information 904 is output. 

The audio information is then routed to a PC 906, which is similar to the PC 112 in 
FIGURE L A user 908 is interfaced with the PC to receive information thereof, the PC 906 
having associated therewith a display (not shown). The PC 906 is interfaced with a netu'ork 
910, similar to the network 306 in FIGURE 3. This network 910 has multiple nodes thereon, 
one of which is the PC 906, and another of which is represented by a network node 912 which 
represents remote information. The object of the present embodiment is to access remote 
information for display to the user 908 by the act of transmitting from the video program in 
block 902 the routing information 904. This routing information 904 is utilized to allow the 
PC 906 which has a network "browser" running thereon to "fetch" the remote information at 
the node 912 over the network 910 for display to the user 908. This routing information 904 
is in the form of an embedded code within the audio signal, as was described hereinabove. 

Referring now to FIGURE 10, there is illustrated a more detailed block diagram of the 
embodiment of FIGUHE 9. In this embodiment, the PC 906 is split up into a couple of nodes, 
a first PC 1002 and a second PC 1004. The PC 1002 resides at the node associated with the 
user 908, and the PC 1004 resides at'another node. The PC 1 004 represents the ARS 308 of 
FIGURE 3. The PC 1004 has a database 1006 associated therewith, which is basically the 
advertiser database 310. Therefore, there are three nodes on the network 910 necessar>' to 
implement the disclosed embodiment, the PC 1002, the PC 1004 and the remote information 
node 912. The routing information 904 is utilized by the PC 1002 for routing to the PC 1004 
to determine the location of the remote information node 912 on the network 910. This is 
retumed to the PC 1 002 and a connection made directly with the remote information node 912 
and the information retrieved therefrom to the user 908. The routing information 904 basically 
constitutes primary routing information. 

Referring now to FIGURE 11, there is illustrated a diagrammatic view of how the 
network packet is formed for sending the primary routing information to the PC 1004. In 
general, the primarv' routing information occupies a single field which primar>' routing 
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information is then assembled into a data packet with the secondary routing information for 
transfer to the network 910. This is described hereinabove in detail. 

Referring now to FIGURE 12, there is illustrated an alternate embodiment to that of 
FIGURE 9. In this embodiment, the video source 902 has associated therewith. an optical 
5 region 1202, which optical region 1202 has disposed therein an embedded video code. This 
embedded video code could be relatively complex or as simple as a grid of dark and white 
regions, each region in the grid able to have a dark color for a logic *'r' or a white region for 
a logic "0." This will allow a digital value to be disposed within the optical region 1202. A 
sensor 1 204 can then be provided for sensing this video code. In the example above, this would 
1 0 merely require an array of optical detectors, one for each region in the grid to determine whether 
this is a logic or a logic "0" state. One of the sensed video is then output to the PC 906 for 
processing thereof to determine the information contained therein, which information contained 
therein constitutes the primary routing information 904. Thereafter, it is processed as described 
hereinabove with reference to FIGURE 9. 

15 Referring now to FIGURE 13, there is illustrated a block diagram for an embodiment 

wherein a user's profile can be forwarded to the original subscriber or manufacturer. The PC 
906 has associated therewith a profile database 1302, which profile database 1302 is operable 
to store a profile of the user 908. This profile is created when the program, after initial 
installation, requests profile information to be input in order to activate the program. In 

20 addition to the profile, there is also a unique ID that is provided to the user 908 in association 
with the browser program that runs on the PC 906. This is stored in a storage location 
represented by a block 1304, This ED 1304 is accessible by a remote location as a '*cookie" 
which is information that is stored in the PC 906 in an accessible location, which accessible 
location is actually accessible by the remote program running on a remote node. 

25 The ARS 308, which basically constitutes the PC 1004 of FIGURE 10, is operable to 

have associated therewith a profile database 1308, which profile database 1308 is operable to 
store profiles for all of the users. The profile database 1 308 is a combination of the stored in 
profile database 1302 for all of the PCs 906 that are attachable to the system. This is to be 
distinguished from information stored in the database 310, the advertiser's database, which 
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contains intermediate destination tables. When the routing information in the primary routing 
information 904 is forwarded to the ARS 308 and extracted from the original data packet, the 
lookup procedure described hereinabove can then be performed to determine where this 
information is to be routed. The profile database 1302 is then utilized for each transaction, 
wherein each transaction in the form of the routing information received from the primary 
routing information 904 is compared to the destination tables 310 to determine what 
manufacturer it is associated with. The associated ID 1304 that is transmitted along with the 
routing information in primar>^ routing information 904 is then compared with the profile 
database 1308 to determine if a profile-associated therewith is available. This information is 
stored in a transaction database 1310 such that, at a later time, for each routing code received 
in the form of the information in primary routing information 904, there will associated 
therewith the IDs 1 304 of each of the PCs 906. The associated profiles in database 1 308, which 
are stored in association with IDs 1304, can then be assembled and transmitted to a subscriber 
as referenced by a subscriber node 13 12 on the network 910. The ARS 308 can do this in n\'o 
modes, a realtime mode or a non-realtime mode. In a realtime mode, each time a PC 906 
accesses the advertiser database 310, that user's profile information is uploaded to the 
subscriber node 1312. At the same time, billing information is generated for that subscriber 
1312 which is stored in a billing database 1316. Therefore, the ARS 308 has the ability to 
inform the subscriber 1312 of each transaction, bill for those transactions, and also provide to 
the subscriber 1312 profile information regarding who is accessing the particular product 
advertisement having associated therewith the routing information field 904 for a particular 
routing code as described hereinabove. This information, once assembled, can then be 
transmitted to the subscriber 1312 and also be reflected in billing information and stored in the 
billing information database 1316. 

Referring now to FIGURE 14, there is illustrated a flowchart depicting the operation 
for storing the profile for the user. The program is initiated in a block 1402 and then proceeds 
to a function block 1404, wherein the system will prompt for the profile upon initiation of the 
system. This initiation is a function that is set to activate whenever the user initially loads the 
soft\vare that he or she is provided. The purpose for this is to create, in addition to the setup 
information, a user profile. Once the user is prompted for this, then the program will flow to 
a decision block 1406 to determine whether the user provides basic or detailed information. 



wo 01/57780 



PCT/USOl/02762 



19 

This is selectable by the user. If selecting basic, the program will flow to a function block 1 408 
wherein the user will enter basic information such as name and serial number and possibly an 
address. However, to provide some incentive to the user to enter more information, the original 
prompt in function block 1404 would have offers for such things as coupons, discounts, etc, if 
the user will enter additional information. If the user selects this option, the program from the 
decision block 1406 to a function block 1410. In the function block 1410, the user is prompted 
to enter specific information such as job, income level, general family history, demographic 
information and more. There can be any amount of information collected in this particular 
function block. 

Once all of the information is collected, in either the basic mode or the more specific 
mode, the program will then flow to a function block 1412 where this information is stored 
locally. The program then flows to a decision block 1414 to then go on-hne to the host or the 
ARS 308. In general, the user is prompted to determine whether he or she wants to send this 
information to the host at the present time or to send it later. If he or she selects the "later ' 
option, the program will flow to a function block 1 4 1 5 to prompt the user at a later time to send 
the information. In the disclosed embodiment, the user will not be able to utilize the software 
until the profile information is sent to the host. Therefore, the user may have to activate this 
at a later time in order to connect with the host. 

If the user has selected the option to upload the profile infoimation to the host, the 
program will flow to the function block 1416 to initiate the connect process and then to a 
decision block 1418 to determine if the connection has been made. If not, the program will 
flow along a "N" path to a time to decision block 1420 which will time to an error block 1422 
or back to the input of the connect decision block 1418. The program, once connected, will 
then flow along a *'Y" path from decision block 1418 to a function block 1428 to send the 
profile information with the ID of the computer or user to the host. The ID is basically, as 
described hereinabove, a ''cookie'' in the computer which is accessed by the program when 
transmitting to the host. The program will then flow to a function block 1430 to activate the 
program such that it, at later time, can operate without requiring all of the set up information. 
In general, all of the operation of this flowchart is performed with a *'wizard" which steps the 
user through the setup process. Once complete, the program will flow to a Done block 1432. 
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Referring now to FIGURE 15, there is illustrated a flowchart depicting the operation 
of the host when receiving a transaction. The program is initiated at a start block 1 502 and then 
proceeds to decision block 1504, wherein it is determined whether the system has received a 
routing request, i.e., the routing information 904 in the form of a tone, etc., embedded in the 
audio signal as described hereinabove with respect to FIGURE 9. The program will loop back 
around to the input of decision block 1 504 until the routing request has been received. At this 
time, the program will flow along the "Y" path to a function block 1506 to receive the primary 
routing information and the user ED. Essentially, this primary routing information is extracted 
from the audio tone, in addition to the user ID. The program then flows to a function block 
1508 to look up the manufacturer URL that corresponds to the received primary routing 
information and then return the necessary command information to the originating PC 108 in 
order to allow that PC to connect to the destination associated with the primary routing 
information. Thereafter, the program will flow to a function block 1510 to update the 
transaction database 13 10 for the current transaction. In general, the routing information 904 
will be stored as a single field with the associated IDs. The profile database, as described 
hereinabove, has associated therewith detailed profiles of each user on the system that has 
activated their software in association with their ED. Since the ID was sent in association with 
the routing information, what is stored in the transaction database is the routing code, in 
association with all of the EDs transmitted to the system in association w^ith that particular 
routing code. Once this transaction database has been updated, as described hereinabove, the 
transactions can be transferred back to the subscriber at node 312 with the detailed profile 
information fi'om the profile database 1308. 

The profile information can be transmitted back to the subscriber or manufacturer in the 
node 312 in realtime or non-realtime. A decision block 1512 is provided for this, which 
determines if the delivery is realtime. If realtime, the program will flow along a "Y" path to 
a fiinction block 1514 wherein the information will be immediately forwarded to the 
manufacturer or subscriber. The program will then flow to a function block 1516 wherein the 
billing for that particular manufacturer or subscriber will be updated in the biUing database 
1316, The program will then flow into an End block 1518. Ifit was non-realtime, the program 
moves along the ''N" path to a function block 1520 wherein it is set for a later deliver>' and it 
is accrued in the transaction database. In any event, the transaction database will accrue all 
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information associated with a particular routing code. 

With a realtime transaction, it is possible for a manufacturer to place an ad in a 
magazine or to place a product on a shelf at a particular time. The manufacturer can thereafter 
monitor the times when either the ads are or the products are purchased. Of course, they must 
5 be scanned into a computer which will provide some delay. However, the manufacturer can 

gain a very current view of how a product is moving. For example, if a cola manufacturer were 
to provide a promotional advertisement on, for example, television, indicating that a new cola 
was going to be placed on the shelf and that the first 1000 purchasers, for example, scanning 
their code into the network would receive some benefit, such as a chance to win a trip to some 

1 0 famous resort in Florida or some other incentive, the manufacturer would have a very good idea 
as to how well the advertisement was received. Further, the advertiser would know where the 
receptive markets were. If this advertiser, for example, had placed the television advertisement 
in ten cities and received overwhelming response from one city, but very poor response from 
another city, he would then have some inclination to believe that either one poor response city 

1 5 was not a good market or that the advertising medium he had chosen was very poor. Since the 
advertiser can obtain a relatively instant response and also content with that response as to the 
demographics of the responder, very important information can be obtained in a relatively short 
time. 

It should be noted that the disclosed embodiment is not limited to a single source PC 
20 302, but may encompass a large number of source computers connected over a global 
communication network. Additionally, the embodiment is not limited to a single ARS 308 or 
a single advertiser server 312, but may include a plurality of ARS and advertiser systems, 
indicated by the addition of ARS 3 1 4 and advertiser server A 3 1 6, respectively. It should also 
be noted that this embodiment is not limited only to global communication networks, but also 
25 may be used with LAN, WAN, and peer-to-peer configurations. 

It should also be noted that the disclosed embodiment is not limited to a personal 
computer, but is also applicable to, for example, a Network Computer ("NetPC"). ^ scaled- 
down version of the PC, or any system which accommodates user interaction and interfaces to 
information resources. 
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One topical application of the above noted technique is for providing a triggering event 
during a program, such as a sport event. In a first example, this may be generated by an 
advertiser. One could imagine that, due to the cost of advertisements in a high profile sports 
program, there is a desire to utilize this time. widely. If, for example, an advertiser contracted 
for 15 seconds worth of advertising time, they could insert within their program a tone 
containing the routing information. This routing information can then be output to the user's 
PC which will cause the user's PC to, via the network, obtain information from a remote 
location typically controlled by the advertiser. This could be in the form of an advenisement 
of a length longer than that contracted for. Further, this could be an interactive type of 
advertisement. An important aspect to the t>pe of interaction between the actual broadcast 
program with the embedded routing information and the manufacturer's site is the fact that 
there is provided in the information as to the user's PC and a profile of the user themselves. 
Therefore, an advertiser can actually gain realtime information as to the number of individuals 
that are watching their particular advertisement and also information as to the background of 
those individuals, profile information, etc. This can be a very valuable asset to an advertiser. 

In another example, the producer of the program, whether it be an on-air program, a 
program embedded in a video tape, CD-ROM, DVD, or a cassette, can allow the user to 
automatically access additional information that is not displayed on the screen. For example, 
in a sporting event, various statistics can be provided to the user from a remote location, merely 
by the viewer watching the program. When these statistics are provided, the advertiser can be 
provided with profile information and background information regarding the user. This can be 
important when, for example, the user may record a sports program. If the manufacturer sees 
that this program routing code is being output from some device at a later time than the actual 
broadcast itself, this allows the advertisers to actually see that their program is still being used 
and also what type of individual is using it. Alternatively, the broadcaster could determine the 
same and actually bill the advertiser an additional sum for a later broadcast. This is all due to 
the fact that the routing information automatically, through a PC and a network, will provide 
an indication to the advertiser for other intermediary regarding the time at w'hich the acmal 
information was broadcast. 

The different type of medium that can be utilized with the above embodiment are such 
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thinss as advertisements, which are discussed hereinabove, contests, games, news programs, 
education, coupon promotional programs, demonstration media (demos), photographs, all of 
which can be broadcast on a private site or a pubHc site. This all will provide the ability to 
allow realtime interface with the network and the remote location for obtaining the routed 
information and also allow for realtime billing and accounting. 

Referring now to FIGURE 1 6, there is illustrated a general block diagram of a disclosed 
embodiment. A bar code scanning input device 1 600 is provided by a input device distributor 
to customers and is associated with that distributor via a input device DD stored therein. The 
input device 1600 is either sold or freely distributed to customers for use with their personal 
computing systems. Since more and more products are being sold using bar codes, it can be 
appreciated that a user having the input device 1600 can scan bar codes of a multitude of 
products in order to obtain more information. Information about these products can be made 
immediately available to the user from the manufacturer for presentation by the user's computer 
302. Beyond simply displa>ang information about the product in which the user is interested, 
the input device distributor may include additional advertising information for display to the 
user such as information about other promotions or products provided or sold by the input 
device distributor. Similarly, advertisers may provide catalogs of advertisements or information 
in newspapers or periodicals where the user simply scans the bar code associated with the 
advertisement using the input device 1600 to obtain further information. There is provided a 
paper source 1602 having contained thereon an advertisement 1604 and an associated bar code 
1 606. (Note that the disclosed concept is not limited to scanning of bar codes 1606 from paper 
sources 1602, but is also operable to scan a bar code 1606 on the product itself. Also, the input 
device 1600 can be any type of device that will scan any type of image having information 
encoded therein.) 

After obtaining the input device 1600 from the input device distributor, the user 
connects the input device 1 600 to their PC 302. During a scanning operation, input device 1 600 
reads bar code data 1 606 and the input device ID into a *Vedge" interface 1 608 for conversion 
into keyboard data, which keyboard data is passed therefrom into the keyboard input port of PC 
302. The importance of the input device ID will be discussed in more detail hereinbelow. In 
general, the input device is a keystroke automator, 
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The wedge interface 1608 is simply an interface box containing circuitry that 
accommodates inputs from both the scanning input device 1 600 and a computer keyboard 1610. 
This merely allows the information scanned by the input device 1600 to be input into the 
PC302. In the disclosed embodiment, the wedge interface 1608 will convert any information. 
The data output from the input device 1600 is passed into the wedge interface 1608 for 
conversion into keyboard data which is readily recognizable by the PC 302.. Therefore, the 
input device 1600 is not required to be connected to a separate port on the PC 302. This data 
is recognized as a sequence of keystrokes. However, the output of the input device 1600 can 
be input in any manner compatible with the PC 302. When not receiving scanner data, the 
wedge interface 1 608 simply acts as a pass-through device for keyboard data from the keyboard 
1610. In any case, the information is ultimately processed by a processor in the PC 302 and can 
be presented to the user on a display 1612. The wedge interface is operable to provide a 
decoding function for the bar code and conversion thereof to keystroke input data. 

In operation, the product code of a product is provided in the form of a bar code 1 606. 
This bar code 1 606 is the "link" to a product. The disclosed embodiment is operable to connect 
that product information contained in the bar code 1606 with a web page of the manufacturer 
of that product by utilizing the bar code 1606 as the product "identifier." The program 
operating on the PC 302 provides routing information to the ARS 308 after launching the 
browser on the PC 302 and connecting to the ARS 308 over the GCN 306, which ARS 308 then 
performs the necessary steps to cause the browser to connect to the manufacturer web site, 
while also providing for an accounting step, as will be described in more detail hereinbelow. 

The bar code 1606 by itself is incompatible with any kind of network for the purposes 
of communication therewith. It is primarily provided for a retail-type setting. Therefore, the 
information contained in the bar code 1606, by itself, does not allow for anything other than 
identification of a product, assuming that one has a database 1614 containing information as 
to a correlation between the product and the bar code 1606. 

The wedge interface 1608 is operable to decode the bar code 1606 to extract the 
encoded information therein, and append to that decoded bar code information relating to an 
ID for the input device 1600. This information is then forwarded to the .ARS by the resident 
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program in the PC 302. This is facilitated by intermediate routing information stored in the 
program indicating to which node on the GCN 306 the scanned bar code information is to be 
sent, i.e., to the ARS 308. It is important to note that the information in the bar code 1 606 must 
be converted from its optical image to numerical values which are then ultimately input to the 
keyboard input port of PC 302 and converted into data compatible with communication 
software residing on the PC 302 (in this case, HTML language for insertion into a browser 
program). When the scanned information is input to the PC 302, the resident program launches 
the browser program and then assembles a communication packet comprised of the URL of the 
ARS 308, the input device ED and the user ID. If another type of communications program 
were utilized, then it would have to be converted into language compatible with that program. 
Of course, a user could actually key in the information on the bar code 1 02 and then append the 
appropriate intermediate routing information thereafter. As will be described hereinbelovv, the 
intermediate routing information appended thereto is the URL of the ARS 308 disposed on the 
GCN 306. 

As part of the configuration for using the input device 1600, the PC 302 hosts input 
device software which is operable to interpret data transmitted from the input device 1 600, and 
to create a message packet having the scanned product information and input device ID, routing 
information, and a user ED which identifies the user location of the input device 1600. The 
input device software loads at boot-up of the PC 302 and runs in the background. In response 
to receiving a scanned bar code 1606, the wedge interface outputs a keystroke code (e.g., ALT- 
FIO) to bring the input device program into the- foreground for interaction by the operating 
system. The input device program then inserts the necessary information into the browser 
program. The message packet is then transmitted to interface 304 across the global 
communication network 306 to the ARS 308. The ARS 308 interrogates the message packet 
and performs a lookup ftinction using the ARS database 310. If a match is found between 
particular parameters of the message packet, a retum message packet is sent back to the PC 302 
for processing. 

The input device program running on PC 302 ftinctions to partition the browser window 
displayed to the user into several individual areas. This is for the purpose of preparing to 
present to the user selected information in each of the individual areas (also called "framing"). 
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The selected information comprises the product information which the user requested by 
scanning the bar code 1606 using the input device 1600, information about the input device 
distributor which establishes the identity of the company associated with that particular input 
device 1600, and at least one or more other frames which may be advertisements related to 
5 other products that the input device distributor sells. Note that the advertisements displayed 

by the input device distributor may be related to the product of interest or totally unrelated. For 
example, if a user scans the bar code 1606 of a Company A soda, the input device distributor 
may generate an advertisement of a new soft drink being marketed by Company A, that it sells. 
On the other hand, the input device distributor may also structure the display of information to 
10 the user such that a user requesting product information of a Product X may get the requested 
information of Product X along with advertisements for a competing item Product Y. 
Essentially, the input device distributor is free to generate any advertisement to the user in 
response to the user requesting product information. 

The return message packet transmitted from the ARS 308 to the PC. 302 is then 
15 transmitted back across the GCN 306 to the advertiser server 312. The advertiser server 312 

restructures the message packet and appends the particular product information for transmission 
back to the PC 302. Upon receiving the particular advertiser information from advertiser ser\'er 
312, the PC 302 then retransmits a message to the input device distributor site 1616 and E- 
commerce site 1618 to obtain the information that needs to be framed in the browser window 
20 displayed to the user 

Therefore, the input device 1600 is associated with the input device distributor by way 
of a input device ED such that scanning a product bar code 1 606 in order to obtain information 
about that particular product generates one or more responses from one or more remote sites 
disposed on the GCN 306. Stored in the input device 1600 is the input device ID which 

25 estabhshes its relationship to the input device distributor. Proprietary input device softv^'are 
ruiuiing on the PC 302 operates to decode scanned bar code information and the input device 
ED received from the input device 1600 and wedge interface 1608, and also provides a unique 
user BD for establishing the location of the user of the input device 1600. The input device 
software also assembles message packets and works in conjunction with the on-board 

30 communication software (e.g., a browser) to automatically route the message packets across the 
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GCN 306 such that the one or more remote sites disposed on the GCN 306 return infarmation 
to be framed for presentation to the usen 

Referring now to FIGURE 17, there is illustrated a conversion circuit of the wedge 
interface. A microcontroller 1 700 provides conversion of the data from the input device 1600 
and controls interfacing of the keyboard 1610 and input device 1600 with the PC 302, The 
microcontroller 1700 has contained therein a memory 1702 or it can have external memory. 
There are provided a plurality of input device interfaces 1704 to the input device 1600, a 
plurality of PC interfaces 1706 to the PC 302, and plurality of keyboard interfaces 1 708 to the 
keyboard 1 06. In general, the input device interfaces 1 704 comprise a serial data line, a ground 
line, and a power line. Similarly, the keyboard interfaces 1708 comprise a serial data line, a 
ground hne, a clock line, and a power line. The PC 302 provides a clock line, a power line, a 
serial data, and a ground line for input to the friicrocontroller 1 700. The microcontroller 1 700 
is operable to receive signals from the keyboard 1610 and transfer the signals to the PC 302 as 
keyboard signals. Operation with the keyboard 161 0 is essentially a ''pass-through" procedure. 
Data output from the keyboard 1610 is already in keyboard format, and therefore requires no 
conversion by the wedge interface 1608. With respect to the input device 1600, the serial data 
is not compatible with a keyboard 1610 and, therefore, it must be converted into a keyboard 
format in order to allow input thereof to the keyboard input of the PC 302. 

The microcontroller 1700 performs this function after decoding this bar code 
information, and conversion of this bar code information into an appropriate stream of data 
which is comprised of the bar code information and the appended URL. This appended URL 
will be pre-stored in the memory 1702 and is programmable at the time of manufacture. It is 
noted that the memory 1702 is illustrated as being contained within the microcontroller 1702 
to provide a single chip solution. However, this could be external memory that is accessible 
by the microcontroller 1702. Therefore, the microcontroller 1700 provides an interface between 
the input device 1600 and the keyboard 1 610 to the PC 302 which allows the input device 1 600 
to receive coded information and convert it to keyboard strokes or, alternatively, to merely pass- 
through the keystrokes from the keyboard 1610, Therefore, the user need not install any t>pe 
of plug-in circuit board into the motherboard of the PC 302 in order to provide an interface to 
the input device 1600; rather, the user need only utilize the already available keyboard port in 
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order to input the appropriate data into the system. 

In this particular disclosed embodiment, the microcontroller 1700 comprises a 
PICl 5C73 microcontroller by Microchip Technologies^^^, The PICl 6C73 device is a low cost 
CMOS 8-bit microcontroller with an integrated analog-to-digital converter. The PIC16C73 
5 device, as illustrated in the disclosed embodiment, has 192 bytes of RAM and 4k x 4 of 

EPROM memory. The microcontroller 1 700 can accommodate asynchronous or synchronous 
inputs from input devices connected to it. In this disclosed embodiment, communication to the 
keyboard 1 6 1 0 is synchronous w^hile it is asynchronous when communicating with input device 
1600. 

10 It should be noted that, although in this particular embodiment bar code information of 

the bar code 1606 is input into the keyboard input port of the PC 302, disclosed methods may 
also be advantageously utilized with high speed port architectures such as Universal Serial Bus 
rUSB") and IEEE 1394. 

Bar codes are structured to be read in either direction. Timing considerations need to 
15 be addressed because of the variety of individuals scanning the bar code introduce a wide 
variety of scan rates. Bar codes use bars of varying widths. The presence of a black bar 
generates a positive pulse, and the absence of a black bar generates no pulse. Each character 
of a conventional bar code has associated therewith seven pulses or bars. Depending on the 
width of the bars, the time between pulses varies. In this disclosed embodiment, the interface 
20 circuitry 1 608 performs a ''running" calculation of the scan time based upon the rising edge of 
the pulses commencing with the leader or header information. The minimum and maximum 
scans times are calculated continuously in software with the interface 1 608 during the scanning 
process to ensure a successful scan by the user. 

Referring now to FIGURE 1 8, there is illustrated a sample message packet transmitted 
25 from the user's PC 302 to the ARS. The message packet 1 800 comprises a number of bits of 

information including the bar code information 1802 obtained from the user scanning the bar 
code with the input device 1600; the input device ID 1804 which is embedded in a memor>' in 
the input device 1 600 and identifies it with a particular input device distributor; and a user ED 
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1 806 which is denved from the software running on the PC 302 and which identifies uniquely 
with the user location. Note that the message packet includes other necessary information for 
the proper transmission for point to point. 

Referring now to FIGURE 19, there is illustrated a more detailed block diagram of the 
5 routing of the message packets in order to present the framed information to the user. As is 

mentioned hereinabove, when the user scans a bar code 1606 using the input device 1600, a 
input device program running on the user PC 302 is operable to interpret the information output 
by the input device 1600 and generate a message packet for transmission over the GCN 306. 
The input device program assembles the message packet such that it is directed to the ARS 308 

10 disposed on the GCN 306. The message packet contains several pieces of information 
including the input device ID 1804 which links it to the input device distributor, the user ID 
1 806 which identifies the particular user using the input device 1 600, and bar code information 
describing a particular product of interest to the user. This message from the PC 302 is 
transmitted over a path 1 900 to the ARS 308 where the ARS database 3 1 0 is accessed to cross 

15 reference the ED information and bar code information to a particular advertiser and input 

device distributor. The ARS 308 returns a message packet over a path 1 902 to the user PC 302 
which contains routing information as to the location of various other sites disposed on the 
GCN 306, for example, the advertiser server 312 and input device distributor site 1616. 

It can be appreciated that other information can also be provided by the ARS 308 which 
20 more closely targets the particular user of the input device 1600. For example, if it is known 
that a particular input device 1600 is sold in a certain geographic area, this information can be 
useful in targeting the particular user with certain advertising information relevant to that 
geographic area. In any case, the information returned from the ARS 308 over path 1902 
provides enough information for the input device program running on the user PC 302 to 
25 identify a number of other sites disposed on the GCN 306. The userPC 302 then processes the 

return message packet and routes another message packet over a path 1904 to the advertiser 
server 312. The advertiser sender 3 1 2 then returns product information of the particular product 
in which the user w^as interested back to the user PC 302 over a path 1 906. Similarly, the user 
PC 302 routes information (e.g., the URL of the input device distributor site and the user 
30 profile) to the input device distributor site 1616 over a path 1908 in order to obtain information 
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back over a path 1910 for framing any banners which identify the input device distributor. 
Additionally, the user PC 302 forwards a message packet to the E-commerce site 1618 over a 
path 1912 in order to return information regarding any particular advertisements the input 
device distributor wants to display to the user. The advertisements are returned to the PC 302 
over a path 1914. 

Referring now to FIGURE 20, there is illustrated a block diagram of a browser window 
according to the disclosed embodiment. The browser window 2000 is partitioned into a 
plurality of areas for framing specific information. A bar code area 2002 displays that product 
information in which the user was interested; a input device specific area 2004 displays 
infonnation about the input device distributor; and an E-commerce area 2006 displays 
advertising information that the input device distributor" selects for display according to this 
particular user and input device 1600. As mentioned hereinabove, a program operable to 
process scanned bar code information with the unique input device 1 600 develops the browser 
window by partitioning it into specific areas for the framing of information. Therefore, 
information returned from the E-commerce site 1608 is passed through the GCN 306 to the 
particular E-commerce frame 2006. Similarly, information about the particular product of 
interest is returned from the advertiser site 312 across the GCN 306 to the particular bar code 
specific area 2002. Information placed in the input device specific area 2004 is information 
about the input device distributor which is retumed from the input device distributor site 1616 
across GCN 306. 

Referring now to FIGURE 21, there is illustrated a structure of information contained 
in the ARS database. The ARS database 310 contains a variety of information required to 
properly interrogate and assemble packets for obtaining information from the various sites 
disposed on the GCN 306. The ARS database 310 has a database structure 2100 which 
contains addresses for the web sites containing the product information requested by the user 
when scanning the bar code 1 606 with the input device 1600. Under a* product heading 2 1 02 
are listed the particular bar codes and associated routing information for addressing the 
respective sender location. For example, the ARS server 308 may contain any number of 
advertisers having unique URL addresses associated therewith. Therefore, the bar code 1 606 
of a panicular product is associated with a unique URL address which routes any request for 
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information of that product to that particular advertiser's site. Also part of the ARS database 
structure 2000 is a heading of input device under which is the input device ID 1804 and the 
distributor associated with that input device BD 1804. 

It can be appreciated that there may be a number of distributors using the disclosed 
architecture such that each distributor has an ID embedded in the input device which uniquely 
identifies that input device with the particular distributor. Therefore, the unique input device 
ED 1804 needs to be listed with the respective distributors of that input device 1600 in order to 
process the information that needs to be framed and displayed to that particular user. Another 
heading under the ARS database structure 2 1 00 is a user heading 2 106 which contains profile 
information associated with that particular user ED 1806. As mentioned hereinabove, the user 
ED 1 806 is obtained via the input device software rurming on the PC 302 and upon installation 
or subsequent configuration may request that the user input certain profile information which 
may be used to target that particular user with products and services which identify with that 
user profile. The ARS database structure 2100 also contains an E-commerce heading 2108 
which contains information related to the bar code 1606 and an advertisement that may be 
triggered by the'^ request for that information. For example, any bar code 1 606 associated with 
a paper source 1600 can be associated with the specific information in the ARS database 310. 
A user wishing to obtain information about a specific soft drink may, in fact, trigger an 
advertising response of a competitor product. Similarly, the user interested in information 
about that particular soft drink may also trigger information which is relevant to that particular 
product or a product which may normally be served in conjunction with that soft drink. 
Furthermore, if the user profile indicates that this individual has significant interest in finance 
or insurance, the request for information regarding this particular bar coded product may trigger 
advertisement from an E-commerce server 1618 related to information about finance and 
insurance. It should be noted that the information described as contained within the ARS 
database structure 2100 is not limited to what has been described, but may comprise any 
number of pieces of information used to present desired information to the computer display 
of the user. 

Referring now to FIGURE 22, there is illustrated a flowchart of the process of receiving 
information from the user's perspective, and according to the disclosed embodiment. The input 
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device software running on the user's PC 302 runs in the background until activated by output 
fi-om the input device 1 600. Therefore, flow moves to a decision block 2200 where if a scanned 
input does not occur, flow moves out the "N*' path and loops back to the input of decision block 
2200. On the other hand, if scanned input information is received, flow moves out the "Y" path 
5 to a function block 2202 where the input device software assembles a message packet 

containing the bar code information, the input device ID 1 804 and the ARS 308 URL address. 
Additionally, the browser is launched in which this information is placed for transmission to 
the .AJIS 308. Flow then moves to a function block 2204 where the browser is partitioned into 
any number of areas in which information is displayed when obtained from the input device 
10 distributor site 1616, the E-commerce site 1618, and the advertiser server 312. It should be 
known that although three frames are shown in the particular window 2000 of this embodiment, 
the number of frames displayed in the window 2000 is limited only by the available real estate 
of the window 2000 area itself 

After the input device software partitions the browser window into one or more frames 
15 in preparation of receipt of return information, flow moves to a decision block 2206 where the 
computer waits for information to be returned from the various sites disposed on the GCN 306. 
If information is not returned, flow moves out the *'N" path and simply loops back to the input 
to continue monitoring for receipt of the information. If information has been received, flow 
moves out the "Y" path to a function block 2208 where routing information for each frame (or 
20 partitioned area of the window 2000) is inserted into one or more packets for transmission to 
the various sites. The various sites then return the requested information back to the PC 302, 
as indicated in fiinction block 2210. Flow is then to a function block 2212 where the 
proprietary software working in conjunction with the hosted browser places the returned 
information into the respective frames of the window. The user, viewing the display at PC 302, 
25 then perceives a variety of information, one of which is the particular product information 

which he or she requested, in addition to input device distributor information, and possibly 
other advertisements based upon the user's profile. 

Referring now to FIGURE 23, there is illustrated a flowchart of the process according 
to the .ARS. The ARS 308 is operable to decode and process message received from the GCN 
30 306. Therefore, flow is to a decision block 2300 where, if bar code information is not received. 
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flow is out the "N" path with loop-back to its input. If bar code information has been received, 
flow is to a function block 2302 where a matching process occurs to link the bar-coded product 
information to its respective manufacturer. The ARS database 310 also associates the URL 
address of the manufacturer's ser\^er. When a match is found, the ARS 308 begins to assemble 
5 a message packet of information for transmission back to the PC 302, as indicated in function 

block 2304. The message packet contains the product information and the URL address of the 
manufacturer's website. Flow then moves to a decision block 2306 where the input device ED 
1804 is compared with the list of input device IDs issued by the particular input device 
distributor. If the input device ID 1 804 is validated, flow moves out the *'Y" path to a function 

1 0 block 2308 where the message packet is appended with the input device ID 1 804 and distributor 
routing address. Flow then moves to a decision block 23 10 where the ARS 308 determines if 
any E-commerce information is to be associated with a particular input device ID 1 804. If so,, 
flow is out the 'V path to a function block 23 12 where the message packet is appended with 
the E-commerce routing string. The E-commerce routing string provides addressing for the E- 

15 commerce server 1618. Flow then moves to a function block 23 14 where all message packets 

are returned back to the PC 302 for processing. 

Referring back to decision block 2306, if the input device ID 1 804 is determined to be 
invahd, flow moves out the "N" path and jumps forward to the input of decision block 2314, 
since the lack of a input device ID 1804 interrupts the link to any advertising provided by the 

20 E-commerce server 1618. At this point, the only information provided is the link to the adverse 
server 312 for return of product information. Referring now to decision block 2310, if no E- 
commerce information is available, flow moves out the "N" path and jumps forward to the 
input of function block 2314 where the message packet back to the PC 302 contains only the 
URL of the advertiser server 3 1 2, the bar code information, the distributor server 1616 address 

25 and input device ID 1 804 information. 

Referring now to FIGURE 24, there is illustrated a flowchart of the process performed 
at the E-commerce site. The E-commerce server 1618 receives the message packet from the 
user PC 302, as indicated in function block 2400, and decodes the packet to perform a match 
with the bar coded information. . Moving on to a decision block 2402. if the match is 
30 unsuccessful, flow is out the ''N" path to a function block 2404 where the match is rejected. 
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A message may be returned to indicate that a problem occurred and the user may need to re- 
scan the product bar code 1606. If a successful match occurs, flow moves out the path to 
a function block 2406 where the input device ED 1804 is matched with the bar code product 
information. The bar coded information may be distributed to customers over a large 
geographic area. However, the input device 1606 maybe coded for certain geographic areas. 
For example, a input device 1600 having an XXX ED may be restricted for sale in the 
Southwestern United States while a input device 1 600 having a YYY ED may be sold only in 
the Northeast. In this way, geographic areas may be targeted wdth advertising more appealing 
to that particular area. Advertising returned to the user PC 302 may be focused further by 
obtaining a user profile when the software or input device 1600 are installed. In this way, 
advertising may be focused based upon the user profile. Therefore, flow moves to a function 
block 2408 to lookup the E-commerce action based upon the input device ED 1 804 and the bar 
code information. Flow moves to a function block 2410 to assemble all the information into 
a packet for return to the user PC 302. The product information and/or user profile information 
may be returned. Flow is then to a function block 2412 where the message packet is 
transmitted. 

. Referring now to FIGURE 25, there is illustrated a general diagram in the context of a 
disclosed embodiment. The scanner 1600 is configured to be operable with a computer 302 
having the display 1612 running a software interface compatible with the scanner 1600. and 
which enables operation of the scanner 1600. The system is operable such that handshaking 
occurs between the scanner 1600 and the software interface. In one configuration, the scanner 
1 600, operable to read optically encoded information 1606, interfaces through the wedge 1 60S 
to the keyboard input 2500 of the computer 302. As mentioned hereinabove, the w^edge 1 60S 
provides conversion of information to a keyboard-type format, such that hardware interfacing 
to the wedge 1608 transmits information which is received by the computer 302 into the 
keyboard input port 2500 as recognizable keyboard-formatted information, i.e., keystrokes. The 
computer keyboard 1610 passes infomiation through the wedge 1608 into the computer 302 
which does not require conversion, since the information is already in the desired keyboard 
format. It can be appreciated that, optionally, with the more recent advances in serial bus 
technology, that a scanner 1600 having USB (Universal Serial Bus) compatibility can be 
connected directly to a USB input port 2502. The software interface then provides ihe 
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necessary scanner 1600 information conversion such that the optically encoded information 
1 606 is properly interpreted. Of course, other serial bus technologies (e.g., IEEE 1 394) can also 
be utilized with the disclosed architecture. 

The software interface performs the handshaking operation on a regular basis to ensure 
that incompatible devices capable of performing the same or similar operation can not be^ 
substituted after system startup. Similarly, the scanner 1600 contains intelligence operable to 
ensure that a third-party software interface can not be substituted to operate the scanner 1600. 
This secure handshaking can be obtained via several scenarios. In the optional context 
mentioned hereinabove, the scanner 1600 comprises a processor and non-volatile memory 
which stores encoded information which can only be unlocked and interpreted by the 
appropriate software interface running and communicating via the USB port 2502 on the 
computer 302. Upon successful handshaking, the software interface then enables the optical 
read head of the scanner 1600 such that it can read the optically encoded information 1606. 

Where the wedge 1 608 is used, the same handshaking can be provided via the keyboard 
port 2500 through the wedge 1608 to the scanner 1600. If, in this embodiment, the scanner 
comprises the processor and non-volatile memory, the scanner can be made operable under the 
same circumstances mentioned hereinabove. The software interface performs the necessary 
handshaking through the keyboard port 2500. In the scenario where the scanner 1 600 lacks a 
processor and non- volatile memory, the scanner 1600 and wedge 1608 can be provided to the 
user as a set such that the scanner 1600 requires the wedge 1608 for operation. The \\^edge 
1608, having the processor and memory, then performs the handshaking with the software 
interface in order to enable operation of the optical head for scanning information. This makes 
it more difficult for those enterprising individuals who attempt to substitute an unauthorized 
scanner 1600 in place of an approved scanner 1600, and/or unauthorized software for use with 
the scanner 1600 and wedge 1608. This protective measure ensures that product support can 
be more effectively provided. 

Referring now to FIGURE 26, there is illustrated a more detailed block diagram of a 
disclosed embodiment. The scanner 1 600 is show^n having ports capable of accommodating 
either a serial bus connection for the computer serial connection 2502 to the computer 302, or 
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a connection to the wedge 1 608. Note that these connections are possible using a scanner 1 600 
manufactured for either a USB port 2502 connection or a wedge 1 608 interface connector. The 
scanner 1600 is illustrated with a processor 2600 having a non-volatile (NV) memory 2602 
associated therewith. The NV memory 2602 stores the secure handshaking code required for 
5 operation with the software interface running on the computer 302. The processor 2600 
controls a switch 2604 which enables or disables a sensor head 2606 which reads the optically 
encoded information 1 606, The processor 2600 communicates with the computer 302 through 
one or more input/output (VO) circuits; an L/O interface 2608 for direct connection to the USB 
port 2502 of the computer 302, and a keyboard interface 2610 for use with the wedge 1608. 

10 The computer 302 comprises standard devices such as a processor 2612 having an 

associated memory 26 1 4, a mass storage unit 26 1 6, a computer keyboard interface circuit 2618 
having the keyboard port 2500, and a serial I/O interface circuit 2620 having the serial I/O port 
2502 for serial devices, e.g., USB devices. In operation, the software interface operates from 
the memory 2614 during execution by the computer processor 2612 to communicate with the 

15 scanner processor 2600 to perform the secure handshaking operation in order to enable the 
operation of the scanner 1600. The operation can be configured to perform the enabling 
operation only once during power-up of the scanner 1600, wedge 1608, and computer 302 
systems, or the configuration can be such that a reenabling command can be sent to the scanner 
1600 on a regular basis after power-up of the system, e.g., ever>' 2 seconds. The enabling 

20 command is transmitted to the scanner processor 2600 in response to a successful code- 
matching process between the scanner processor 2600 and the computer processor 2612. 

In a configuration where the scanner 1 600 lacks a processor 2600, but contains the NV 
memory 2602 having a code, the computer 320 or the wedge 1608 may access the NV memory 
2602, after power-up, and perform the code-matching operation for ultimate enablement of 
25 scanner 1600 operation. Using this method, the computer processor 2612, or the wedge 
processor 1 700 operates the scanner switch 2604 to turn on the sensor head 2606. This method 
may introduce more wires into the cable connection 1 704, but reduces the cost of parts for the 
scanner 1 600 by eliminating the scanner processor 2600. 

When the configuration requires use of the wedge 1608, the wedge processor 1700 
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having associated memory 1 702 acts as a slave device to the computer processor 26 12, and can 
either perform the handshaking operation directly with the scanner 1600, reporting the results 
back to the computer processor 2612, or merely pass-through the handshaking exchange 
occurring between the computer processor 2612 and the scanner NV memor>' 2602. This 
5 exchange occurs through the keyboard port 2500 across connection 1706 to the wedge 

processor 1700, and then on to the scarmer NV memory 2602. Normal operation of the 
keyboard 1610 occurs across the keyboard connection 1 708 through the wedge processor 1 700 
into the computer 302 without any conversion, since its signals are already in the format 
required by the computer keyboard interface circuit 261 8. 

10 Referring now to FIGURE 27, there is illustrated an alternative embodiment 

incorporating a network. The global communication network 306 is provided as a mechanism 
across which scanner 1600 operation is enabled. The user obtains the scanner and software 
interface, and upon installation, registers the software and scanner by submitting unique 
numbers associated with each of the scanner 1600 and the software interface to a central 

15 registration server (CRS) 2700 having an associated CRS database storage unit 2702. The 

registration process is required for operation of the scanner 1600. 

In one facet of this alternative embodiment, the operation of the scanner 1600 is 
dependent upon the software interface maintaining communication with the CRS 2700 such that 
a reenabling '*seed" is transmitted from the CRS 2700 back to the user computer 302 to 

20 maintain operation of the scanner 1600. The seed can be transmitted regularly, for example, 

ever>' 50- 1 00 milliseconds such that the scanner 1 600 remains enabled for operation by the user. 
An advantage to this method of operation is that the vendor knows precisely when the user is 
on-line. With this information, the vendor can then send advertising back to the user during this 
on-line time. In conjunction with the registration process, a user profile can also be obtained 

25 from the user of the scarmer 1600. The user profile can be used in a number of ways by the 

vendor of the scanner, such as targeting the particular user v/ith advertising during use of the 
scanner 1600. Knowing the user profile information, the advertising can be more focused to 
the particular user offering a greater opportunity to make a sale of the advertised product. 
Additionally/ the vendor can develop or update the user profile provided during initial 

30 registration by tracking the user's activities during their on-line time. 
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In another facet of this alternative embodiment, the enabling handshaking continues 
locally between the software interface and the scanner 1600, as described hereinabove, but the 
sofrsvare interface also provides an in-use flag to the registration sender such that, again, the 
vendor knows precisely when the user is on-line using the scanner to obtain product 
5 information. The vendor can then transmit advertising to the user during the on-line time 

period. 

As mentioned hereinabove, the scanner 1600 is used to scan optically encoded 
information 1606 which is provided on a variety of publications 1602 or products in 
conjunction with an advertisement 1604. When scanned, the product information 1606 has 

10 appended thereto routing information which routes the product information to the .ARS 308. 

A matching operation is performed with the ARS database 310 whereby a vendor web site 
address is obtained. The user computer 302 is then routed to the web site address (advertiser 
ser\^er 312) on the network 306 for presentation to the user of product information related to 
the scanned information 1606 and the advertisement 1604. It can be appreciated that the 

15 function of the CRS 2700 and associated database storage unit 2702 can be consolidated into 

the ARS 308 and ARS database 310, respectively. 

Referring now to FIGURE 28, there is illustrated a flowchart of the operation of the 
scanner and software interface in a local mode. Flow begins at a Start block and proceeds to 
a function block 2800 where the user connects the scanner to the user computer 302. The 

20 connection will be made through the wedge 1 608. Flow is then to a function block 2802 where 
the user powders on the computer 302 such that the enabling process can begin. Flow is then to 
a function block 2804 v/here the computer 302 provides power to the scanner 1 600 through the 
wedge 1608. Flow is then to a function block 2806 where the scanner processor 2600 
initializes and accesses the NV memory 2602 for the stored handshaking code. In substantially 

25 the same time as the scanner 1660 is being initialized, the software interface is launched and 
run in the computer 302, as indicated in a function block 2808. 

When running in local mode, the software interface establishes communication through 
the wedge 1608 to the scanner processor 2600 to begin the enablement process such that the 
scanner 1 600 will operate. In a function block 2810, the handshaking process is performed via 
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a matching operation between the code stored in the scanner NV memory 2602 and the code 
shipped with the software interface. Flow is then to a decision block 2812 to determine if a 
valid match occurred.. If not, flow is out the ''N" path to a function block 2814 where the 
computer processor 2612 signals the scanner processor 2600 to disable the sensor head 2606 
to prevent read capabihty of the scanner 1600. Flow then loops back to the input of function 
block 2810 to repeat the encrypted handshake. If the handshake is valid, flow is out the "Y" 
path of decision block 2812 to a function block 2816 where the computer processor 2612 
signals the scanner processor 2600 to enable the sensor head 2606 by switching power to the 
sensor head 2606 using the head power switch 2604. The computer processor 2612 and the 
scanner processor 2600 then establish a data mode where scanned information is transmitted 
to the wedge 1608 for conversion into keyboard formatted data, and passed from there to the 
keyboard input port 2500 of the computer 302, as indicated in a function block 2820. Flow is 
then back to the input of function block 2810 to perform the handshake to maintain the 
enablement of the scaimer operation. If, after power-up, the user chooses to substitute an 
unauthorized scanning device for scanner 1600, the handshake operation will fail and the 
scanner will be useless when used with the software interface. 

Referring now to FIGURE 29, there is illustrated a flowchart of operation in a remote 
mode. Flow begins at a Start block and proceeds to a function block 2900 w'here the user 
connects the scanner to the computer 302 via the wedge 1608. The user then powers the 
computer 302, which powers the wedge 1608 and the scanner 1600, as indicated in a function 
block 2902. Flow is then to a function block 2904 where the software interface is executed on 
the computer 302. The user then connects to the GCN 306, as indicated in a function block 
2906 for purposes of operating the scanner 1600. Flow is then to a decision block 2908 to 
determine if the user has registered the scarmer and software interface. If not, flow is out the 
"N"' path to a function block 2910 where the user computer 302 connects to CRS server 2700 
where the user is presented with a registration process. 

Registration requires that a user profile form be completed by the user by entering 
various bits of information comprising, for example, name address, phone number, unique 
number of the scanner 1 600, and unique number of the software interface. The user then 
transmits the user profile information back to the CRS ser\^er 2700, as indicated in a function 
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block 2912. Flow is then to a function block 2914 where the CRS server 2700 sends an 
enabling seed back to the user computer 302 which enables operation of the scanner 1 600. Had 
the user already been registered, flow would then be out the *'Y" path of decision block 2908 
jumping forward to the input of function block 2914 to perform a matching operation at the 
CRS ser\'er 2700 using the profile database stored in the CRS database 2702. The matching 
operation is performed using the unique number of the software interface, which is transmitted 
to the CRS server 2700. Upon a successful match of the unique software interface number, the 
seed is generated based upon the unique numbers of the scanner 1600 and the software 
interface. The CRS server 2700 then sends the enabling seed to the user computer 302. 

Flow continues to a function block 2916 where the handshaking process is then 
performed between the computer processor 2612 and the scanner processor 2600, based upon 
coded information stored in the scanner NC memory 2602 and provided by the software 
interface. In one aspect of the remote operation, the seed received from the CRS server 2700 
is the coded information used in the handshaking operation. In another aspect of the remote 
operation, the seed simply enables the operation of the software such that the handshaking 
operation can be performed between the software-provided unique number and the coded 
information stored in the NV memory 2602 of the scanner 160C. In any case, the seed is 
required form the CRS server 2700 to operate the scanner 1600. Flow is then to a decision 
block 291 8 to determine if a successful handshake has been performed. If not, flow is out the 
"N" path to a function block 2920 to send a disabUng signal to the switch 2604, to cut power 
to the sensor head 2606. If a valid handshake has been performed, flow is out the "Y" path to 
a function block 2922 to enable power to the sensor head 2'606 by switching power through the 
switch 2604. Flow is then back to the input of decision block 2908 to determine if the user has 
already registered the product, and to continue sending the seed signal to enable operation of 
the scanner 1600. 

Although the preferred embodiment has been described in detail, it should be 
understood that various changes, substitutions and alterations can be made therein without 
departing from the spirit and scope of the invention as defined by the appended claims. 



wo 01/57780 



PCT/USOl/02762 



41 

WHAT IS CLAIMED IS: 

1. A method of controlling a scanner with a software interface, comprising the 
steps of: 

providing a scanner operable to read scannable information; 

connecting the scanner to a computer which operates the software interface for 
processing the scannable information; and 

performing an encrypted handshaking operation betv\''een the software interface and the 
scanner prior to allowing the scanner to become operable to read the scannable information. 

2. The method of Claim 1 , wherein the step of performing is performed in a local 
mode where the handshaking operation is enabled locally on a periodic basis during operation 
of the scanner. 

3 . The method of Claim 1 , wherein the step of performing is performed in a remote 
mode where the handshaking operation is enabled remotely by an enabling signal on a periodic 
basis during operation of the scarmer from a registration server disposed on a network common 
to the computer. 

4. The method of Claim 3, wherein the computer is automatically logged in to the 
ser\'er using the software interface during operation in the remote mode to receive the enabling 
signal. 

5. The method of Claim 3, further comprising the step of registering in the remote 
mode such that first-time operation of the software interface requires registering the software 
interface and the scanner by providing user profile information and both of the unique numbers 
to the registration server, in response to which the registration server providing the enabling 
signal for operation of the scanner. 

6. The method of Claim 5, wherein, subsequent to the step of registering, and when 
operating in the remote mode, the computer is automatically logged in to the registration sender 
to perform a matching operation at the registration serx'er with the unique number of the 
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software interface and a registration database, and transmitting the enabling signal to the 
computer in response to a successful match. 



7. The method of Claim 1, wherein the scanner and the software interface each 
have a unique number associated therewith which is used to perform the encrypted handshaking 
in the step of performing. 
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8. .Aji architecture for controlling a scanner with a software interface, comprising: 
a scanner operable to read scannable information; 

a software interface operable to run on a computer which interfaces to the scanner, said 
software interface communicating with the scarmer to interpret the scannable information; 

wherein an encrypted handshaking operation is performed between said software 
interface and the scanner prior to causing the scanner to become operable to read the scannable 
information. 

9. ' The architecture of Claim 8, wherein in a local mode, the handshaking operation 
is enabled locally on a periodic basis during operation of the scanner. 

10. The architecture of Claim 8, wherein in a remote mode, the handshaking 
operation is enabled remotely by an enabling signal on a periodic basis during operation of the 
scanner from a registration server disposed on a network common to the computer. 

1 1 . The architecture of Claim 10, wherein the computer is automatically logged in 
to the server using the software interface during operation in the remote mode to receive the 
enabling signal. 

12. The architecture of Claim 10, wherein first-time operation of the software 
interface in the remote mode requires registering the software interface and the scanner by 
providing user profile infonnation and both of the unique numbers to the registration server, 
in response to which the registration server providing the enabling signal for operation of the 
scanner. 

13. The architecture of Claim 12, wherein the computer is automatically logged in 
to the registration server when operating in the remote mode to perform a matching operation 
at the registration server with the unique number of the software interface and a registration 
database, and transmitting the enabling signal to the computer in response to a successful 
match, 

1 4. The architecture of Claim 8, wherein the scanner and the software interface each 
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have a unique number associated therewith which is used to perform the encrypted handshaking 
in the step of performing. 
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